Why is this the best possible solution? Were any other approaches considered?
This change fixes the problem at the earliest useful point: header parsing. Before this change, a header like form_title::French (fr) was accepted, turned into a nested dict structure, and only failed later during XML generation with the confusing runtime error:

AttributeError: 'dict' object has no attribute 'nodeType'
The new behavior rejects invalid translated headers while parsing sheet columns and raises a clear, user-facing header error that includes the sheet name, full column name, and base column. That is better than a later crash because:

the error is closer to the source of the problem
the message is actionable for form authors
valid translation and grouped-header behavior can still proceed unchanged
I considered implementing a narrow special case just for form_title::..., since that was one of the motivating examples in the issue discussion. I decided against that because the issue is broader: any non-translatable column written in translated form should produce a clear error, not just form_title. The chosen solution generalizes the fix while still allowing supported translated columns and existing grouped headers like attribute::..., media::..., and translated bind/message columns.

What are the regression risks?
Moderate but well contained. The change touches shared header parsing logic, so the main regression risk is accidentally rejecting valid grouped or translated headers.

To reduce that risk, the validation was designed to:

allow known translatable column paths on the relevant sheets
allow valid grouped header roots such as attribute, media, bind, instance, control, and body where appropriate
only raise the new error for recognized columns that are being used in translation form on sheets where that base column is not translatable
I added focused regression tests and also ran nearby translation and namespace/grouped-header tests to confirm the parser still accepts supported cases.

Does this change require updates to documentation? If so, please file an issue here and include the link below.
Maybe, but probably not urgently. This is mainly an error-handling improvement for unsupported usage rather than a change to supported XLSForm behavior. If maintainers want this clarified in user docs, a docs issue could be filed later.